Verification engine for user authentication

ABSTRACT

An aspect of the present invention is embodied in a system for remote user authentication. An entity that wishes to authenticate a user can contact a verification engine, which, in turn, has limited access to a plurality of databases containing personal information about the user. The personal information in the databases is collected and stored by the individual operators of the databases in the ordinary course of their business with the user. The databases allow the verification engine to access the user&#39;s personal information only through predefined queries. The verification engine presents the user with the queries and the user&#39;s responses are presented to each corresponding database operator for validation. The database operators then return a confidence indication for the verification step and the verification engine combines the confidence indication from each database operator into a combined confidence indication used in authentication of the remote user.

RELATED APPLICATIONS

[0001] This application claims priority from U.S. Provisional PatentApp. No. 60/244,422, filed Oct. 30, 2000, which is hereby incorporatedby reference in its entirety.

COPYRIGHT NOTICE

[0002] ©2001 RAF Technology, Inc. A portion of the disclosure of thispatent document contains material which is subject to copyrightprotection. The copyright owner has no objection to the facsimilereproduction by anyone of the patent document or the patent disclosure,as it appears in the Patent and Trademark Office patent file or records,but otherwise reserves all copyright rights whatsoever. 37 CFR§1.71(d)-(e).

TECHNICAL FIELD

[0003] The present invention relates to the field of remote userauthentication and, in particular, user authentication employinginformation stored in multiple, independently controlled databases.

BACKGROUND OF THE INVENTION

[0004] Presently, many systems employ security measures to protectproprietary or highly sensitive information they possess. One commonaspect of the security measures often includes authentication (i.e., theestablishment of identity) of subjects that are using the system. Asused herein, the term “subject” refers to any person or entity beingauthenticated. There are two primary types of authentication: userauthentication and data authentication. User authentication is theprocess of determining whether the subject is who he claims to be. Thereare many possible ways of determining subject identity, and they comewith varying degrees of security. Traditionally, subject authenticationhas been done in three ways: recognition of the subject, sharedknowledge, and possession of a token by the subject.

[0005] When implementing shared knowledge for subject authentication,the system knows things about the subject that should not be commonknowledge. When the subject demonstrates that he also knows thesethings, identification is achieved. The information typically used inthe authentication procedures can be divided into two types: in-walletdata and out-of-wallet data. In-wallet data is information you knowabout yourself or can readily put your hand to. It includes your name,address, telephone number, drivers license number, social securitynumber, checking account number, credit card numbers, mother's maidenname, and the like. This data forms the basis for some of the simplerauthentication systems of the prior art.

[0006] Out-of-wallet data is information about you that would take you alittle effort to find out, but that you probably have in your filingsystem or somewhere equally accessible with some effort. It includesinformation such as the amount of the last transaction with yourcheckbook or credit card, the holder and amount of your mortgage, yourcredit rating, your bank balance, and the like. Incorporatingout-of-wallet information into an authentication system is morecomplicated, and thus, it is found less frequently in typical systems.

[0007] Passwords are a form of both shared knowledge and of tokens. Fora password to work properly, both sides must know it, and only bothsides must know it. Shared knowledge includes some nonobviousinformation as well. The billing address on your credit card, forexample, is known to you, of course, but is accessible from the cardissuer by any merchant who takes that credit card.

[0008] When performing a transaction, it is often necessary to fill outa form containing information important for the transaction. Quite apartfrom the need to authenticate the subject, the data in those forms mustalso be authenticated. Data authentication consists of applying businessrules to the forms at the time of capture. This is done at the point ofrecognition for paper forms, and while the subject is online, in thecase of Web forms. Data authentication can be as simple as ensuring acolumn of numbers adds up, or as complicated as verifying severalassociated tax forms to be sure a particular number was both correctlycalculated and correctly copied.

[0009] In addition to attempting to overcome technological hurdles,typical authentication systems of the prior art must frequently overcomesocial hurdles as well. Many people are concerned with the growingavailability of personal information on the Internet. There are equalconcerns around too much information being stored in one place. This isespecially true when the information is being stored by a governmentalentity, raising “big brother” concerns. An authentication system basedon shared information is more convenient and less expensive for thesubject, but it is more invasive of privacy. A system based on sharedinformation can only work when based on information that only thesubject and the authenticator knows. Because the subject and theauthenticator have no contact other than the current transaction, thismeans that the shared information must be private information about thesubject that the authenticator also possesses.

[0010] Although everyone would prefer to keep private information in thehands of the subject, the alternative to using it is identity theft. Asystem that works entirely online, if denied access to privateinformation, will be exposed to identity theft. One simply cannotprevent identity theft without some form of authentication. It is alsoclear that the security of an authentication system and itsobtrusiveness are inversely related-the more secure the system, theharder it is to make it unobtrusive. This tension inherent inauthentication processes illustrates one of the limitations of proposalssuch as the “national identity card.” There are various proposed usesfor such a card, but primary among them are prevention of identitytheft, limiting social benefits to legal residents, tracking thosederelict in child support and other payments, fighting drug trafficking,providing identification for travelers, and making it easier to trackthose in this country legally or illegally.

[0011] Each of these is a legitimate social concern. Nonetheless, anysystem based on a single card allowing access to a centralized source ofidentity-establishing information suffers from two important drawbacks.The first, is establishing that a presented card is itself legitimate.Although states recently have taken measures to protect their driver'slicenses and ID cards from forgery, fake ID cards are a long-standingproblem. It is, for example, very difficult to establish from an ID cardwhether two people who look alike are actually distinct individuals.

[0012] The security needs of both the nation and the individual citizensmust always be balanced against the requirement to preserve a free andopen society. Authentication system, as viewed on the whole, should notbe deemed overly intrusive.

SUMMARY OF THE INVENTION

[0013] The present invention provides a method and system forauthentication that are more secure, less intrusive, more flexible, andeasier to keep current than the prior art. This is accomplished throughstrategically employing a verification engine for authenticationprocedures.

[0014] The engine accepts personal data from a subject beingauthenticated. Typically, the data can be collected from the subject aspart of a financial transaction with an agency of the federalgovernment, financial institution, or commerce entity, or incident tosome security procedure, etc. As used throughout these systems and theattached claims, the entity requesting authentication of the subject istermed the “authentication client” or “client.” The data collected fromthe subject can then be compared to information contained in independentdatabases. Each database queried returns a confidence rating indicatinghow well the data matches. The verification engine combines these ratingand returns them to the client, which can apply business rules of itsown to decide whether to accept the subject as a valid user. Fuzzy logicalgorithms can be used to determine the various confidence levels.

[0015] There are three main components to the verification engine. Thefirst component controls access to the overall system by users. Itprovides a single interface, with a single set of commands, to allsystem clients. While the interface is standardized, it can still becustomized based on the particular needs of each client. The secondcomponent interfaces with each remote database, speaking the languagerequired by that database, both for querying and for receiving back theanswers to queries. The third component, the verification core, operatesin connection with the other two main components. It recognizes thequeries sent to it by clients, because the queries are predefined basedon the needs of the individual client. The verification core alsopossesses the protocols to translate those queries into queries to theindividual databases, and it can assemble their responses into acoordinated response to the client.

[0016] The verification engine tightly controls the questions it asks ofeach independent database. This enables it to meet the stringent privacyrequirements of many database holders, thus encouraging the use of theirinformation in legitimate ways not previously allowed by the databaseoperators. The verification engine also ties into a broad range ofinformation providers. Because the verification engine has access tomultiple databases that were previously unconnected, it can answerquestions that cannot be answered by any single database. Because theverification engine controls access to those databases in waysestablished through agreement with the database owners, it overcomes thereluctance of many database owners to allow access to their information.Thus, it can include various databases previously unavailable forgeneral use.

[0017] Information is stored where it has a legitimate reason to bestored: with the database owners that acquired the information as partof their ordinary businesses or affairs with the subject. Theverification engine allows legitimate access to personal data concerninga subject being authenticated, but it keeps others from browsing.Authentication clients are only licensed for specific predefinedqueries. Queries designed to browse database records or “read-out”information are not enabled by the verification engine.

[0018] Additional aspects and advantages of this invention will beapparent from the following detailed description of preferredembodiments thereof, which proceeds with reference to the accompanyingdrawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0019]FIG. 1 is a schematic representation of an authentication systememploying a verification engine consistent with the present invention.

[0020]FIG. 2 depicts a specific embodiment of the present invention inthe context of online authentication for an e-commerce transaction.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

[0021] Embodiments consistent with the present invention provide theability to authenticate a subject even if the subject has had no priorcontact with the system and has had no access to digital signatures,certificates, or passwords. One example of such a subject would be aperson who is ready to retire and wants to set up his Social Securitypayments. Such a subject would possess or have the ability to access acomputer and a network connection, such as through the Internet, but heis presumed to be an otherwise unsophisticated user. Another example ofa user requiring authentication would be a subject trying to effect anonline payment at an online store, or a subject trying to effect atransaction with his financial institution. The problem is toauthenticate these subjects without requiring undue effort on the partof the subjects. To facilitate clarity and for ease of discussion, thereferences to the subject herein will assume a remote individual orentity that is accessing the authentication system through a network,such as the Internet. It is equally within the scope of the presentinvention to conduct live, real-time authentication of the subjectin-person.

[0022] A preferred embodiment of the present invention implements averification engine for authenticating a subject using predefinedqueries requesting personal identifying information from the subject.The identifying information comes from multiple third-party databasesthat have gathered that information in the ordinary course of theirbusiness or other relationships and dealings with the subject. Theengine itself can adopt a client-server architecture and can be modeledafter systems such as those used with market success in the postal andform recognition fields. The flexible design can enable processing ofqueries at rates up to 850 per minute and is scalable as demand on thesystem increases.

[0023] There are three main parts to the verification engine. The firstpart controls access to the overall system by authentication clients. Itprovides a single user interface, with a single set of commands, to allsystem users. The queries it can present, as discussed in detail below,however, can be tailored to the particular needs of a specific client.The second part interfaces with each remote database, speaking thelanguage required by that database, both for querying and for receivingback the answers to queries.

[0024] The third part, functions in the middle, connecting the other twomain parts. This part is termed the “verification core.” It understandsthe queries sent to it by users. It knows how to translate those queriesinto queries for the individual databases. The verification core knowswhat questions each connected database can answer, how likely it is toprovide an answer, how long it generally takes to do so, and itpossesses functioning protocols for querying each database. Theverification core can also assemble the responses from the variousindependent databases into a coordinated response to the authenticationclient. The verification core obtains this information throughcollaboration with the independent database operators to develop thespecific queries that will be allowed for use in the authenticationprocedure.

[0025]FIG. 1 illustrates an authentication system incorporating averification engine consistent with the present invention. With respectto FIG. 1, the verification engine 100 includes various components whichinclude a client interface 102, a database interface 104, and theverification core 106. A subject 108 that either gives or requiresauthentication communicates with an authentication client 110. Thesubject 108 can provide identifying information to the authenticationclient 110, and the subject 108 can also answer queries posed by theauthentication client 110. The authentication client 110 gives andreceives information to and from the verification core 106 through theclient interface 102. The verification core can then provide theinformation identifying the subject 108 to one or more independent,third-party databases 112 a through 112 d for authentication. Database“n” 112 d illustrates that a potentially unlimited number of independentdatabases can be provided for authentication with the verificationengine.

[0026] Continuing with FIG. 1, after the subject 108 has identifiedhimself to the authentication client 110, the authentication client 110can present a predefined query 114 to the subject. This predefined queryhas been licensed for a specific use by this authentication client 110.The actual question and scope of the query depend on the authenticationservices being provided by the authentication client 110. The subject108 then returns a response to the query 116. The authentication client110 then forwards 118 the response to the verification engine 100 forauthenticating the subject 108. The verification engine 100 thentransmits 120 a through 120 d the response from the subject 108 tomultiple of the databases 112 a through 112 d. Each database 112 athrough 112 d that receives the information checks it against theidentifying information it stores for the subject 108 and returns aconfidence indication 122 a through 122 d to the verification engine.The verification engine 100 combines the individual confidenceindications 122 a through 122 d into a combined confidence indication124 that is provided to the authentication client 110 for authenticatingthe subject 108.

[0027] On the front end, the verification engine can establishes theidentity of its authentication client with standard digitalcertificates, passwords, and user names. Each authentication client hasa specified list of questions it can ask the system. For example, anairport security guard (in possession of a passenger's driver's license)may only ask such a system “Does John Smith live at 123 Main Street,Jackson, Miss., and have Mississippi Driver's License number549-34-2218?” The only response he can receive back is either a yes or ano, the confidence the system has in that answer, and possibly a pictureof the legitimate holder of the license. He cannot, for example, ask:“who lives at 123 Main Street?”

[0028] If an FBI investigator is the authentication client, on the otherhand, he may be authorized for considerably greater access to thesystem. He may, for example, be able to ask “Give me the passportnumbers of all males of Bahrain residency who entered the United Statesthrough New York or Boston between May 6 and Jun. 7, 2001 on British Airor United Airlines flights from Paris or Zurich.” The scope ofpermissible questioning would depend on the permissions the operator ofthe databases being asked to authenticate the responses would be willingto authorize. Because the system controls access by limiting the kindsof questions each type of user can ask, and because there is no centralrepository of the data, the system is much more protective of privacy.

[0029] On the back end, the system also has tight controls for thequestions it asks of each database. This enables it to meet thestringent privacy requirements of many database holders. The ability tocontrol the types of queries being made against the database providesmany database providers the incentive, or at least comfort level to maketheir database available to the verification engine. The independentdatabase operator can authorize a query to access whatever level ofinformation they are comfortable with. This makes available the use oftheir information in legitimate ways that were not previously possible.

[0030] The verification engine system is designed to be both secure andunobtrusive. In a preferred embodiment, the only data the verificationengine will have direct access to is certain low-sensitivity in-walletdata. This information can come from several commercial sources. Thedata includes name, address, telephone number, and other personalinformation that most people do not consider particularly sensitive, butthat help the engine authenticate a subject at the simplest level. Theinformation can be obtained from the subject as part of a Web form whena person first uses the system. Asking for it as part of a Web formtakes advantage of the habit of filling such information into forms. Ifdone skillfully, most subjects will not even know we are using thatinformation for authentication.

[0031] The more sensitive out-of-wallet data, such as creditworthinessand credit card information, remains in the hands of companies thatnaturally hold that information. Although the verification engine willknow the results of the queries, the information itself is neverdirectly accessible by the verification engine or the authenticationclient. The verification engine simply provides a gateway to theinformation, thus offering a workable compromise between authenticationand privacy. The system also meets the requirements of many governmentalagencies by allowing access to personal data under tightly controlledconditions for legal, social, or medical needs.

[0032] The user information and the specific databases being used forauthentication can vary widely. This affords the present system asignificant amount of flexibility. One perfectly suitable commercialdatabase available to the verification engine is the Crystal Databaseoffered by RAF Technology, Inc. of Redmond, Wash. Compiled from a widerange of reliable sources including the US Postal Service, this databaseis condensed into data crystals that take a fraction of the memory ofthe original and can be rapidly accessed. Crystallizing the data alsoobscures the information so that it cannot be read. As a result, theCrystal Database data crystals can be installed on the verificationengine hardware without actually making the data visible to anyone.Access to the Crystal Database is strictly via predefined queries. Ineffect, the Crystal Database is lent, not given.

[0033] Other databases of personally identifying information can beobtained from such sources as VISANET, the Social SecurityAdministration, the Internal Revenue Service, various of the nationalcredit bureaus, national telephone directory services, etc. State-levelsources of information can also be queried depending on the transactioninvolved. Examples include the Department of Motor Vehicles, the varioustaxation offices, etc.

[0034] Because there are multiple ways to establish identity, Securityor law enforcement personnel can use the personal information databasesin different, and unpredictable ways. Because the information is storedin multiple unrelated databases, it becomes extremely difficult for anidentity thief or other criminal to place false data in all of them.Among the information and combinations it uses to establish identityare: name and aliases plus address; name plus telephone number(s);Social Security Number or other federal identifier; passport number;driver's license number; name plus mother's maiden name; name pluspatronymic; bank account or other financial information; green cardnumber; resident alien number, as well as many others.

[0035]FIG. 2 illustrates the operation of the verification engine in anauthentication system provided for authenticating a subject in anelectronic commerce transaction. In this context, the subject is labeledthe “Customer,” the authentication client is the “e-commerce site,” theindependent databases are the “trusted Validator,” and the verificationengine is being operated by the “Authentex” entity. For simplicity inFIG. 2, the queries and response paths are illustrated as going directlyto the verification engine, rather than through the authenticationclient.

[0036] With reference to FIG. 2, the Customer (box 1) logs onto ane-commerce site (box 15) for which Authentex (box 10) providesauthentication. The system will ask the Customer a series of appropriatequestions (box 8) to authenticate his identity. These questions centeron in-wallet data that Authentex itself possesses, and out-of-walletdata possessed by a trusted Validator (box 3) such as a bank or creditbureau. Authentex holds in-wallet data and provides the gateway toValidators who hold out-of-wallet data.

[0037] The questions are “appropriate” in that they fit the situation.Clearly asking for name, address, phone number, and Social SecurityNumber would be seeking appropriate in-wallet data that can be used toauthenticate the Customer. Choosing appropriate out-of-wallet questionsis more difficult. Out-of-wallet data (box 4) and physical validation ofthe Customer (box 2) were collected by the Validator through the courseof its normal interactions with the Customer, independent of anyconnection with Authentex. The Validators build up a database ofinformation, and a series of queries that can be put to that database.Authentex and the Validator establish a set of allowed queries (box 5)which is a subset of all the queries permitted by the Validator'sdatabase, chosen to provide proper authentication while being asunobtrusive as possible. Effectively, the Validator is digitallyvouching for the Customer.

[0038] Choosing what queries are appropriate can be quite a challenge,and the queries can change with the nature of the requested transaction.If the Customer wants to set up automatic payments to his savingsaccount, an appropriate question would be “what is your savings accountnumber.” Asking for his credit card number would be inappropriate.

[0039] Both in-wallet and out-of-wallet questions (box 8) are presentedas items to be filled out in a Web form. This is far less obtrusive thandirect questions, and seems much more natural to the Customer. In fact,if done skillfully, the Customer will never know he is beingauthenticated at all. The answers (box 9) to in-wallet queries arechecked (box 12) against Authentex's Personal Information Database (box11) and a confidence in the answers (box 13) returned to Authentex. Theanswers (box 9) to out-of-wallet queries are checked (box 6) against theValidator's database and a confidence in the answers (box 7) is returnedto Authentex. Authentex assembles the answers and, using fuzzy logic,determines and passes on its overall confidence (box 14) to thee-commerce site, which makes the final authentication decision.

[0040] It should be noted that the verification engine cansimultaneously serve multiple authentication clients. Similar, eachauthentication client employ the verification engine to authenticatemultiple subjects.

[0041] The present invention also provides a suitable solution to the“national identity card” debate. The verification engine fulfills thelegitimate needs of a national identity system and information bank,while meeting the privacy concerns of individual citizens. It meets theneeds of citizens by leaving their personal data in the possession ofthose whom they perceive as having legitimate need for open access toit.

[0042] It will be obvious to those having skill in the art that manychanges may be made to the details of the above-described embodiments ofthis invention without departing from the underlying principles thereof.The scope of the present invention should, therefore, be determined onlyby the following claims.

1. A user authentication system comprising: an authentication client forrequesting authentication of a subject; a user interface to receive theauthentication request from the authentication client; multipleindependently operated databases, each database storing informationassociated with the subject, the associated information being accessiblethrough predefined queries to identify the subject; and a verificationengine for facilitating authentication of the subject by receiving theauthentication request, selecting one or more of the predefined queries,presenting the one or more selected queries to the subject via theauthenticating client, receiving from the subject an answer to each ofthe one or more selected queries, and presenting the answer to themultiple independently operated databases for a validation response. 2.The system of claim 1 wherein the associated information in the multipleindependently operated databases includes out-of-wallet data identifyingthe subject.
 3. The system of claim 1 further comprising a personalinformation database coupled to the verification engine, the personalinformation database containing in-wallet data identifying the subject.4. An authentication system comprising: an authentication client fordesiring authentication of an authentication subject; a plurality ofindependent database systems storing information identifying theauthentication subject, the identifying information being accessiblethrough predefined queries; and a verification engine to receive fromthe authentication subject, via the authentication client, an answer toeach of the predefined queries, to obtain from each of the plurality ofindependent database systems a corresponding authentication confidencefor each answer, and to combine the corresponding authenticationconfidence for each answer into a combined authentication confidence. 5.A user authorization method comprising the steps of: presenting to anauthentication subject one or more predefined queries from each ofmultiple independent databases of identifying information; receivingfrom the authentication subject an answer to each of the selectedqueries; presenting each answer to at least one of the multipleindependent databases that has corresponding identifying information;obtaining from the multiple independent databases an authenticationconfidence level for each answer; and combining the authenticationconfidence level for each answer into a combined confidence level forauthenticating the authentication subject.